寫到第二十六篇，剛好碰上一個和我名字相同的數字。

大家平常叫我 26。如果這個系列裡有哪一篇適合談談我自己，大概就是這篇了。

不過，今天不是要介紹名字的由來，而是想問一個比較實際的問題：如果微光每件事都得找 26，這個地方能走多遠？

上一篇文章，我談到增加新功能之前，需要先想好怎麼不弄壞原本正在使用的東西。

就算每一次更新都處理得很仔細，還是有一個問題會慢慢出現。

功能越多，需要照顧的事情也越多。

有人詢問使用方式，有人回報問題，活動需要整理，角色設定需要調整。這些事情單獨看，可能都不大。但如果每一件都必須等我想起來、找資料，再親自處理，微光能維持的規模，就會受到我當下時間與心力的限制。

所以，除了繼續增加內容，我也需要思考：哪些事情不必每次從頭做，以及哪些判斷仍然應該由我負責。

做出來之後，才開始有日常工作
開發新功能時，目標通常比較明確。

原本不能做的事情，現在可以做了。按鈕出現、流程走通，很容易感受到進度。

但維護不太一樣。

整理一份說明、確認一筆異常交易，或回答成員遇到的問題，不一定會讓微光看起來增加了什麼，卻影響既有功能能不能繼續被使用。

如果我只把時間留給新內容，這些工作就容易累積。

最後可能出現一種情況：功能很多，介紹卻找不到；活動辦過了，後續事情還沒處理；某個問題有人提過，但沒留下清楚紀錄，之後又重新問了一次。

這讓我需要把維護當成原本就會發生的工作，而不是做完功能之後，有空再處理的附帶事項。

先看哪些事情一直重複出現
想到減少負擔，很容易立刻想到自動化。

但我想先知道，自己究竟在反覆做什麼。

有些工作只是每次都要重新找同一份資訊。有些是流程不清楚，所以成員需要一直詢問。也有些確實是固定步驟，適合交給程式執行。

這幾種情況，需要的改善不一樣。

如果大家總是在問同一個功能入口，可能先把入口放清楚，比增加一個自動回答的 Bot 更直接。如果每次活動收尾都要重新想一次檢查項目，則可以先留下簡單清單。

我不希望微光最後最萬用的功能說明，只有三個字：「問 26。」

它偶爾很好用，但我睡覺的時候，這個入口就不太穩定。

不一定所有重複工作，都需要新系統。我想先減少不必要的事情，再處理那些仍然需要重複執行的部分。

文件要能幫助下一次處理，而不只是記錄做過什麼
我希望留下來的文件，能回答實際工作會遇到的問題。

這個功能的規則在哪裡？目前採用哪個版本？有人回報異常時，先查什麼？哪些操作不能直接重做？

如果一份文件只有開發過程，卻找不到目前怎麼使用與維護，下次處理時仍然要重新推理。

因此，我想把「當時怎麼做」和「現在應該怎麼處理」分開整理。

不是每個功能都需要很長的文件。有時候，一個清楚的入口，連到目前規則、操作方式與已知限制，就已經能省下很多時間。

而且，這些內容不只寫給別人看。隔了一段時間之後，我自己也會忘記當初的細節。文件能讓未來的我少依賴記憶，而不是每次都回頭翻聊天紀錄。

適合自動化的，是規則清楚的那一部分
有些工作，確實可以交給程式或 AI 協助。

例如，依固定條件整理資料、產生待確認的摘要，或檢查必要欄位是否齊全。這些事情如果有明確輸入與預期結果，就比較容易驗證。

但「可以自動整理」，不代表「可以自動決定」。

收到一項建議之後，可以先整理成容易判斷的內容。至於要不要投入開發、是否改變既有規則，仍然需要另外作決定。

同樣地，系統可以找出可能有問題的交易，卻不能在原因不明時，擅自重複發獎或扣款。

我想把自動化用在能減少重複勞動的地方，同時保留重要決策的界線。不能只是把原本需要我想清楚的事情，換成讓 AI 更快地下結論。

交出去的工作，要有清楚的起點與終點
如果要讓另一個人、程式或 Agent 接手，也需要讓對方知道究竟要完成什麼。

只說「幫我處理一下」，很容易留下太多解讀空間。

我需要交代目前情況、要達成的結果、可以使用的資料，以及不能碰的範圍。遇到哪些情況要停下來，也應該先說明。

例如，整理回報和修改正式資料，是不同工作。確認問題原因，也不等於已經取得重新啟動服務的許可。

交接得清楚，才比較容易在最後確認成果。否則，對方可能很努力地做了很多事情，我卻仍然不知道原本的問題有沒有被解決。

這也是為什麼文件和工作紀錄，不只是行政負擔。它們能讓接手的人少猜一點，也讓我不用一直站在旁邊補充背景。

自動化也會出問題，所以要有人能接回來

把工作交給系統，不表示我就可以完全不管。

排程可能沒有執行，外部服務可能失敗，AI 也可能理解錯誤。如果沒有結果紀錄或異常提示，只是把原本看得見的工作，變成藏在背景裡的問題。

所以，我希望每項自動化至少能讓人知道：它有沒有執行、做到哪裡，以及是否需要協助。

但通知也不能太多。如果每個正常步驟都傳來一則訊息，我很快又會被新的管理工作淹沒。

比較合適的方向，是把一般結果留在可以查閱的位置，真正需要判斷或處理的異常，再集中提醒。

自動化應該減少照看的負擔，而不是要求我全天確認它有沒有正常工作。

留下需要我決定的事情，不是把所有事情都留給我
有些判斷，我仍然想親自參與。

微光接下來往哪個方向發展、什麼值得投入時間、怎麼處理規則上的爭議，這些事情和我想經營的社群有關，不能只靠固定流程代替。

但如果我每天都忙著查找入口、重複解釋同一件事，真正需要思考的問題就會被擠到後面。

因此，減少日常瑣事的目的，不只是讓我少做一點。

我希望把心力留給那些確實需要理解情境、作出取捨的事情，也留給原本喜歡的創作與交流。

如果最後我只能以管理者的身分出現，一進來就在處理問題，卻沒有餘裕和朋友聊天，那也偏離了我想做微光的初衷。

我希望有人叫「26」的時候，也可以只是想找我看一張圖、聊一個點子，不是每次都代表哪裡壞了。

有些功能，可以先不要做
維護負擔不只靠工具解決，也需要靠取捨。

每增加一項功能，都可能增加說明、測試、處理異常與更新的工作。即使開發本身很快，後續也不一定便宜。

所以，我需要把「做出來要花多少時間」和「留下來要花多少心力」一起考慮。

有些點子很有趣，但目前沒有足夠的維護空間，就可以先放著。有些既有功能若長期沒有明確用途，也值得重新評估。

這不代表看到使用量低，就直接關掉。仍然要了解有沒有人依賴它，以及調整後會受到什麼影響。

但我不能只因為已經做過，就假設所有東西都應該永遠增加、不再減少。

我希望自己不在時，日常也能繼續
我不想把微光做成一個完全不需要人的地方。

有人願意回應、理解情況並負責，仍然很重要。我想減少的是每件小事都必須等待同一個人的狀況。

常見問題有地方查，固定工作有明確流程，接手時有足夠背景，出現異常也知道怎麼停下來求助。這些安排能讓我暫時離開時，日常不必一起停住。

等我回來，需要處理的事情也有清楚紀錄，不必先從一堆散落的訊息猜起。

我希望微光能走得久一點，不只靠某一段時間特別旺盛的熱情。

為此，我需要做的可能不只是下一個新功能，也包括讓已經存在的東西，能被好好照顧。

寫到第二十六篇，我想替自己留下一個提醒：

微光可以有很多地方看得出 26 的想法，但不必每一個地方，都等著 26 出現才能繼續。